Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

The manager templates

The Progress Dynamics manager has one basic characteristic that distinguishes it from other business logic procedures: it runs on both sides of the AppServer connection. In this way it shares one key characteristic of the SmartDataObject, which enables you to write code for it in the AppBuilder just as you do for SDOs or SDO logic procedures in a dynamic application. The template for new managers has the DB-AWARE flag set on to tell the AppBuilder to allow you to write code into this single procedure file and to designate whether that code should be compiled and executed for the client, for the server, or for both.

The DB-AWARE flag is, first of all, a preprocessor value in the template, as shown:

/* ******************** Preprocessor Definitions ******************** */ &Scoped-define PROCEDURE-TYPE Procedure &Scoped-define DB-AWARE YES

You can also set the DB-AWARE flag in special Procedure Settings comments that the AppBuilder parses when it reads in a file for editing. The preprocessor allows your code to reference the DB-AWARE flag, and this internal setting prevents the value from being changed, which would disable the manager, as shown:

/* *********************** Procedure Settings ************************ */ &ANALYZE-SUSPEND _PROCEDURE-SETTINGS /* Settings for THIS-PROCEDURE Type: Procedure Allow: Frames: 0 Add Fields to: Neither Other Settings: CODE-ONLY APPSERVER DB-AWARE NO-PROXY */ &ANALYZE-RESUME _END-PROCEDURE-SETTINGS

In addition to the DB-AWARE setting, there is a setting for the AppBuilder’s information called NO-PROXY. This setting tells the AppBuilder that, unlike for an SDO, the AppBuilder should not actually generate the client proxy when you save the manager procedure.

There are several reasons for this:

First, in the case of the SDO (or the similarly constructed SBO), the client proxy is always given a filename that is the same as the base procedure, but with the extension _cl. The external request runs the base procedure name, and the internal logic of the SDO (or, more precisely, the constructObject call in its container code) determines whether in fact it is that server-side procedure or the client proxy that should be run, depending on the session configuration. The client proxy is never run explicitly. This naming convention is not appropriate for managers, where either the client procedure or the server procedure is explicitly registered with the Session Type as the proper procedure to run when the session starts up. Therefore you can give the client procedure any name you want. For the sake of consistency, follow the existing Progress Dynamics convention of using a common prefix followed by srvrp.p for the server-side procedure and clntp.p for the client side, but there is no requirement that you follow this pattern.
Second, all the parts of an SDO, including the base procedure (customerfullo.w, for example), its companion include file that defines the SDO temp-table, the client proxy procedure, and the logic procedure where you write validation logic, are considered a single unit in Progress Dynamics. Only the base procedure is registered in the Repository when you save the SDO. This is not the case for managers, because either the client or the server version of the manager is run for a given session type, and therefore both the client procedure and the server procedure must be individually registered.
Third, if you do not want to save the client procedure to the same directory as the server procedure, the AppBuilder is not set up to save different procedures to different directories as part of a single operation. Progress Dynamics uses a convention of saving only procedures in the framework that will run on the AppServer in the app directory.
Fourth, the client procedure normally never changes once it has been generated because it is really just two lines of code: one line sets a flag called DB-REQUIRED that tells the compiler to compile out database references, and a second line includes the server procedure. All the real code for both sides is in the server procedure; only the DB-REQUIRED flag tells the compiler which code to compile for which version.

So, for all these reasons, the AppBuilder does not generate or manage the client procedure for you. You can create the client procedure yourself by copying the template for it and naming the server filename that it should include.

The two template procedures that you use to build new managers are ry/app/rytemsrvrp.p and ry/obj/rytemclntp.p. The first is opened for you when you create a new manager in the AppBuilder, and the second you copy and edit yourself.